Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@apps/commerce-api/src/main/java/com/loopers/application/favorite/FavoriteFacade.java`:
- Around line 27-30: The current flow in FavoriteFacade (after calling
favoriteService.addFavorite(command)) calls
productService.increaseLikeCount(product.getId()) but swallows Redis cache
failures inside that call; change the logic so FavoriteFacade detects
cache-update failures from productService.increaseLikeCount (e.g., propagate a
specific exception or return a result/status), and handle it by either
triggering a retry path or marking the operation as partially failed and
enqueuing a background/sync job; specifically update
productService.increaseLikeCount to surface cache errors (throw
CacheUpdateException or return a boolean/status), then in FavoriteFacade check
that result and on failure: (a) attempt a limited retry, or (b) record an async
reconciliation task (or flag) to resync cache and emit an alert/event so the DB
remains authoritative until cache is reconciled.

In
`@apps/commerce-api/src/main/java/com/loopers/application/product/dto/FindProductListReqDto.java`:
- Around line 5-9: FindProductListReqDto currently holds a plain-text password
field which will be included in the compiler-generated toString(); remove
sensitive data by eliminating the password component from the record signature
(pass only an authenticated memberId/principal into controllers) or, as a
short-term mitigation, override FindProductListReqDto#toString() to mask or omit
the password field so it never appears in logs; update callers of
FindProductListReqDto to stop supplying raw credentials and add tests asserting
toString() does not contain the password and that product listing still works
when password is removed.

In
`@apps/commerce-api/src/main/java/com/loopers/domain/favorite/service/FavoriteService.java`:
- Around line 51-53: The null-check currently only guards memberId but will
throw NPE when productIds is null; in FavoriteService (the method containing the
lines checking memberId and productIds) add a null-guard for productIds (treat
null as empty) so the method returns an empty Set instead of NPE (e.g., expand
the condition to if (memberId == null || productIds == null ||
productIds.isEmpty()) return Set.of()); update/ add a unit test that calls the
same service method with a valid memberId and productIds == null and asserts an
empty Set is returned.
- Around line 30-33: In FavoriteService's method that currently catches
DataIntegrityViolationException and always returns false, change the catch so it
distinguishes duplicate-key/unique-constraint violations from other integrity
errors: if the exception indicates a duplicate registration (check
SQLState/constraint name/root cause message on the caught
DataIntegrityViolationException or NestedSQLException) return false; otherwise
rethrow the exception (preserving the original cause) so upstream error handling
and monitoring can detect real data/schema integrity problems; add tests for
concurrent duplicate registration returning false and for a non-duplicate
integrity violation to assert the exception is propagated.

In
`@apps/commerce-api/src/main/java/com/loopers/domain/product/repository/ProductCacheRepository.java`:
- Around line 24-30: The cache-aside init race in resolveLikeCount can overwrite
concurrent INCR updates: change initLikeCount to perform an atomic "set if
absent" instead of a blind set by replacing RedisCacheManager.setCount usage
with a SETNX-based operation (or wrap the init in a Lua script that sets the key
only if it does not exist and returns whether it set) so that existing values
(e.g., from concurrent incrementLikeCount) are preserved; update
RedisCacheManager to expose setIfAbsent or an atomic Lua initializer and call
that from initLikeCount, and add an integration test that simulates two
concurrent cache-miss threads calling resolveLikeCount (and concurrent
incrementLikeCount) to assert no increments are lost.

In
`@apps/commerce-api/src/main/java/com/loopers/domain/product/service/ProductService.java`:
- Around line 93-101: The DB and cache updates in increaseLikeCount and
decreaseLikeCount are not atomic—if
productCacheRepository.incrementLikeCount/decrementLikeCount fails after the
productRepository change, DB and Redis diverge; update these methods to catch
cache update failures and, on failure, evict the product’s like cache key (call
productCacheRepository.evictLikeCount or equivalent) so subsequent reads reload
from DB, and also log the cache error with sufficient context for monitoring;
ensure resolveLikeCount and initLikeCount behavior remains unchanged so eviction
triggers reload, and add tests simulating Redis failure to verify graceful
degradation.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/product/cache/ProductCacheRepositoryImpl.java`:
- Around line 65-68: initLikeCount currently calls RedisCacheManager.setCount
which unconditionally overwrites the key and can race with concurrent
increment()/decrement() calls; add a RedisCacheManager.setCountIfAbsent(String
key, long count, long ttlSeconds) that uses opsForValue().setIfAbsent(...) (SET
NX with TTL) and change ProductCacheRepositoryImpl.initLikeCount(Long productId,
long count) to call setCountIfAbsent(KEY_PREFIX + productId + LIKES_SUFFIX,
count, TTL_SECONDS) instead of setCount; propagate and handle the boolean result
(log on false) so initialization only occurs when the key is absent.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/product/entity/ProductLikeStatsEntity.java`:
- Around line 11-19: There are two separate sources of truth for like counts
(product_like_stats.like_count represented by ProductLikeStatsEntity and
ProductEntity.likeCount), which risks inconsistency; choose a single
source-of-truth and unify reads/writes accordingly: either remove
ProductLikeStatsEntity and its table and update ProductJpaRepository (the
increment/decrement query at ProductJpaRepository) and ProductService (methods
around line ~93-101) to use only ProductEntity.likeCount, or retain
product_like_stats as the authoritative store and change ProductService and
ProductJpaRepository so all like increment/decrement and reads use
ProductLikeStatsEntity (and corresponding queries) while deleting/ignoring
ProductEntity.likeCount; also add integration tests exercising repeated like
toggles, concurrent updates, and cache-miss recovery to ensure DB-cache-response
consistency.

In
`@apps/commerce-api/src/main/java/com/loopers/support/cache/RedisCacheManager.java`:
- Around line 60-76: The increment/decrement methods in RedisCacheManager
currently swallow exceptions and return null and have no TTL support, causing
DB-cache drift; update RedisCacheManager.increment and .decrement to surface
failures and accept an optional TTL (e.g., Duration ttl) or return a boolean
success indicator so callers (like ProductService) can detect failure and
trigger rollback or recovery; specifically, change
writeTemplate.opsForValue().increment(key) and .decrement(key) usage to a
variant that sets TTL when a new key is created (or call expire when increment
creates the key), throw a runtime exception on Redis operation errors instead of
returning null, and ensure initLikeCount remains compatible while ProductService
checks the success/exception to perform cache recovery/rollback logic.

In `@apps/commerce-api/src/main/java/com/loopers/support/enums/SortFilter.java`:
- Around line 11-16: Fix the non-deterministic ordering in
SortFilter.toOrderSpecifier by adding a unique secondary key to stabilize ties:
for PRICE_ASC return ordering by product.price.asc() then product.id.desc(), and
for LIKES_DESC return product.likeCount.desc() then product.id.desc() (LATEST
can remain product.id.desc()). Update the switch in SortFilter.toOrderSpecifier
to compose these two OrderSpecifier values using QProductEntity (product) so the
overall ordering is deterministic. Also add tests that place products with
identical price or likeCount on the boundary between page 0 and page 1 and
assert no duplicates or missing items across pagination.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/product/ProductIndexPerformanceTest.java`:
- Around line 346-362: The test prints the entire INDEX_CANDIDATES as "최종 선택
인덱스" even when some candidates (e.g., idx_product_brand_like_price) were
rejected by measurement; fix by computing selected and rejected sets from the
measurement results instead of printing INDEX_CANDIDATES directly: use the
existing perIndex and allIndex measurement outputs to build explicit
selectedIndexes and rejectedIndexes (or extract that logic into a new method
like determineSelectedIndexes(perIndex, allIndex)), update the print block to
iterate selectedIndexes for the "최종 선택 인덱스" and rejectedIndexes for "미선택 근거",
and add a unit test for the new decision method to assert that candidates with
no improvement are placed in rejectedIndexes.
- Around line 84-118: The benchmark seeding is non-deterministic and doesn't
exercise soft-deletes or stable favorite distributions; update
ProductIndexPerformanceTest seeding to (1) create a deterministic soft-delete
ratio by setting deleted_at for a fixed subset of products (e.g., every Nth
product) when building the product INSERT loop (reference the product INSERT
block and the deleted_at column), (2) replace the RAND() favorite INSERT with a
deterministic rule (e.g., member_id and product_id modulo pattern) in the
favorite INSERT statement so favorites are repeatable and reproducible
(reference the favorite INSERT SELECT query), and (3) compute and persist
like_count in the product rows to match the deterministic favorites (reference
like_count field) and add assertions that re-seeding is idempotent and that
queries using WHERE deleted_at IS NULL and ORDER BY use the expected index.
Ensure changes are deterministic across runs and add small tests to verify
favorite distribution and soft-delete ratio remain identical on repeated
seeding.
- Around line 69-131: The setUp() method must clear existing data and guarantee
rollback/EntityManager closure on exceptions: at the start of setUp() run
DELETEs in order favorite -> product -> member -> brand within a transaction,
then perform the seed inserts; wrap the whole logic in try { begin transaction;
cleanup; seed; commit } catch(Exception e) { if (em.getTransaction().isActive())
em.getTransaction().rollback(); throw e; } finally { if (em != null &&
em.isOpen()) em.close(); } so that setUp(), the cleanup/seed SQL blocks, and
transaction handling are updated accordingly to always rollback on error and
always close the EntityManager.
- Around line 18-21: The ProductIndexPerformanceTest class currently annotated
with `@SpringBootTest` (and importing MySqlTestContainersConfig) is an expensive,
non-failing benchmark; separate it into a manual benchmark suite and replace CI
usage with small, deterministic tests: create a lightweight CI test that loads a
tiny fixed dataset and runs EXPLAIN on the target query, asserting the EXPLAIN
"key" and "type" values, and add a small integration test that explicitly drops
the expected index and verifies the query performance/regression fails (so
absence of index breaks the test). Locate the class ProductIndexPerformanceTest
and its heavy setup (`@SpringBootTest`, MySqlTestContainersConfig) to move to a
manual-only benchmark, and add two new tests: one unit/CI test that asserts
EXPLAIN key/type on the query, and one integration test that removes the index
and asserts failure, ensuring you scope test data setup/cleanup and avoid
long-running data loads in CI.
- Around line 157-185: The 3rd-phase block that creates all indexes (loop over
INDEX_CANDIDATES, executing candidate[1]) must be wrapped in a try-finally so
that after measuring via measureAllQueries(em) you explicitly DROP each created
index (execute the corresponding candidate[2] or generated drop SQL) in the
finally, and always call em.close() in that finally to guarantee EntityManager
is closed on both normal and exceptional flows; additionally add a pre-test
cleanup in setUp() to iterate INDEX_CANDIDATES and DROP any leftover candidate
indexes before the baseline measurement to ensure test isolation between runs.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/product/ProductQueryPerformanceTest.java`:
- Around line 104-135: The test ProductQueryPerformanceTest leaks EntityManager
if an exception occurs and lacks assertions: wrap the EntityManager
creation/usage (the local variable em created from entityManagerFactory and all
calls to em.createNativeQuery(...).getResultList() and em.close()) in a
try-finally (or try-with-resources equivalent) to ensure em.close() always runs,
and add a deterministic performance assertion (e.g., assertTrue or
assertLessThan) against the measured elapsed value (the long elapsed from the
timed loop) with a chosen threshold so the test fails on regressions; also
include a simple assertion that the explain result (explain variable from
em.createNativeQuery("EXPLAIN ...").getResultList()) is not empty to validate
query planning.
- Around line 138-173: The test method materializedView_brandFilter_likeSort
currently only prints timings and lacks documentation, assertions, and
isolation; update it by (1) adding a method-level comment stating this is a
benchmark comparing denormalized vs materialized view query patterns for
intentional non-production query shape, (2) introduce warm-up iterations and
aggregate measurements into a List or stats object and assert against a baseline
threshold or relative comparator (e.g., average <= baselineMs or within
acceptable variance) instead of only System.out.println, and (3) ensure test
isolation by adding or using `@BeforeEach` and `@AfterEach` hooks (or transaction
rollback) to prepare/clean test data so repeated runs don't interfere and to
reduce flakiness; reference materializedView_brandFilter_likeSort, any shared
EntityManagerFactory setup, and the EXPLAIN call when capturing result details
for assertions.

In
`@apps/commerce-api/src/test/java/com/loopers/support/cache/RedisCacheManagerTest.java`:
- Around line 46-155: Tests for the count-related methods are missing; add unit
tests covering RedisCacheManager.increment, decrement, getCount, and setCount:
for increment/decrement add a success case (mock
writeTemplate.opsForValue().increment/ decrement to return a value and assert
it) and an error case (mock writeTemplate.opsForValue() to throw and assert
null), for getCount add cache hit (mock readValueOps.get to return numeric
string and assert parsed Long), cache miss (null -> empty/absent behavior), and
parse-failure (non-numeric value -> handle/assert expected behavior), and for
setCount assert writeValueOps.set is called with correct key/value/TTL and that
Redis exceptions do not throw; locate mocks and interactions around
readTemplate, writeTemplate, readValueOps, writeValueOps, and objectMapper in
RedisCacheManagerTest to implement these tests.

---

Outside diff comments:
In
`@apps/commerce-api/src/main/java/com/loopers/domain/product/model/Product.java`:
- Around line 39-49: The public signature of Product.reconstruct was changed to
require a seventh likeCount parameter and broke existing tests; either restore a
6-arg overload or update all callers. Fix by adding a new overloaded static
method Product.reconstruct(Long id, Long brandId, String name, int price, int
stock, DisplayStatus displayStatus) that delegates to the 7-arg
Product.reconstruct(...) with likeCount = 0L, or alternatively update the three
test call sites (ProductServiceTest, ProductTest, ProductFacadeTest) to pass the
new likeCount argument and add a new test asserting default reconstruct behavior
sets likeCount to 0L. Ensure you modify the Product.reconstruct method(s) and
tests referencing reconstruct accordingly.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/product/repository/impl/ProductCustomRepositoryImpl.java`:
- Around line 33-44: The constructor projection is passing
productEntity.displayStatus (EnumPath<DisplayStatus>) into ProductItem's
constructor which expects a String, causing ExpressionException; update both
occurrences where Projections.constructor(ProductItem.class, ...) is used to
replace productEntity.displayStatus with
productEntity.displayStatus.stringValue() so the query returns a String that
matches ProductItem's 7th parameter, and add QueryDSL-based repository
integration tests asserting that list and detail queries produce valid
ProductItem instances (no ExpressionException) for both active and non-active
statuses.

---

Nitpick comments:
In
`@apps/commerce-api/src/main/java/com/loopers/domain/product/repository/ProductCacheRepository.java`:
- Line 16: CachedPage's items list is mutable externally; change the record to
defensively copy/wrap the list so the internal collection is immutable. Update
the record CachedPage(List<ProductItem> items, long totalElements) to assign
this.items = List.copyOf(items) (or
Collections.unmodifiableList(List.copyOf(items))) in a compact constructor (or
use a static factory) so stored items cannot be modified from outside; reference
CachedPage and ProductItem when applying the change.

In
`@apps/commerce-api/src/main/java/com/loopers/domain/product/repository/ProductRepository.java`:
- Around line 28-30: Add Javadoc to the ProductRepository methods
increaseLikeCount(Long id) and decreaseLikeCount(Long id) that explicitly states
the int return value represents the number of affected rows, what a 0 return
means (e.g. product not found / no update), and any error/exception behavior to
mirror the existing decreaseStock contract; update the method comments for
consistency with decreaseStock so callers know to handle a 0 return as a
failure/no-op.

In
`@apps/commerce-api/src/main/java/com/loopers/domain/product/service/ProductService.java`:
- Around line 65-69: The current loop in ProductService
(result.getContent().forEach -> productCacheRepository.initLikeCount(...))
causes N separate Redis SETs; change ProductCacheRepository to add a batched API
(e.g., initLikeCounts(Map<Long,Long>) or initLikeCounts(List<Pair<Long,Long>>)
and implement it in RedisCacheManager using MSET or a pipelined set to perform
the writes in a single round-trip; update ProductService (where
isFirstPageLatest calls productCacheRepository.putFirstPage(...)) to build the
id->count map from result.getContent() and call the new batched method instead
of per-item initLikeCount.
- Around line 138-147: resolveLikeCount currently reads DB and then calls
productCacheRepository.initLikeCount(productId, count), which can race with
concurrent INCR/DECR and overwrite updated counts; switch to a compare-and-set
or "setCountIfAbsent" pattern in ProductCacheRepository (use a new method like
setCountIfAbsent(productId, count) instead of initLikeCount) so the cache is
only initialized when absent, and log a cache-miss event when falling back to
the DB to aid monitoring; update resolveLikeCount to call
productCacheRepository.setCountIfAbsent(productId, count) after reading
product.getLikeCount() and emit a short debug/info log indicating a cache miss
for productId.
- Around line 108-120: decreaseStockAtomic currently calls
productRepository.findById twice and can misclassify a missing product as "out
of stock"; fix by loading the product once with productRepository.findById in
decreaseStockAtomic (throw NOT_FOUND if absent), check in-memory
product.getStock() < quantity and throw BAD_REQUEST if insufficient, then call
productRepository.decreaseStock(productId, quantity), evict caches via
productCacheRepository.evict(...) / evictFirstPage(), and return the updated
product (update the in-memory product's stock or re-load only if necessary);
alternatively, if you prefer to keep optimistic DB update, replace the first
findById with existsById before calling decreaseStock and only re-query when
updatedRows==0 to distinguish NOT_FOUND vs BAD_REQUEST.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/favorite/entity/FavoriteEntity.java`:
- Around line 11-13: The new single-column index idx_favorite_product_id on the
FavoriteEntity (table "favorite") to speed up countByProductId is fine, but when
adding it in migrations for production with large data you must create the index
using MySQL online DDL options to avoid table locks; update the migration that
creates idx_favorite_product_id to use "ALTER TABLE favorite ADD INDEX
idx_favorite_product_id (productId) ALGORITHM=INPLACE, LOCK=NONE" (or the
equivalent in your migration tool), and include a rollback/remove index step and
a note to validate MySQL version (>=8.0) before applying.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/favorite/repository/FavoriteJpaRepository.java`:
- Line 13: The repository method findByMemberIdAndProductIdIn in
FavoriteJpaRepository must guard against very large productIds lists (DB IN
limits/perf); change callers or add a new repository helper that splits
productIds into configurable chunks (e.g., <=1000) and executes repeated
findByMemberIdAndProductIdIn calls, aggregating and deduplicating results, or
implement an alternative approach (temporary table/join or batch native query)
if available; ensure chunk size is configurable and document/update usages to
call the new batched helper instead of passing an unbounded list directly to
findByMemberIdAndProductIdIn.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/favorite/repository/impl/FavoriteRepositoryImpl.java`:
- Around line 47-52: Add a defensive guard at the start of
FavoriteRepositoryImpl.findByMemberIdAndProductIds to immediately return an
empty List when productIds is null or empty, avoiding unnecessary DB calls and
potential IN () errors; update the method that currently calls
favoriteJpaRepository.findByMemberIdAndProductIdIn to check productIds.isEmpty()
(and null) before invoking the repository, and add unit tests for both null and
empty productIds cases to assert an empty result is returned.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/product/cache/ProductCacheRepositoryImpl.java`:
- Around line 87-92: toItem currently hardcodes favoriteCnt to 0L which is
intentional because ProductCacheDto lacks that field and callers call
resolveLikeCount() then withFavoriteCnt() to set the true value; add a brief
clarifying comment inside the toItem method noting this design (favorite count
is stored/updated separately for atomic INCR/DECR, initialized to 0 here and
overridden by resolveLikeCount()/withFavoriteCnt()), referencing
ProductCacheDto, toItem, resolveLikeCount, and withFavoriteCnt so future
maintainers understand the separation.

In
`@apps/commerce-api/src/main/java/com/loopers/support/cache/RedisCacheManager.java`:
- Around line 30-41: 현재 RedisCacheManager의 public <T> Optional<T> get(String
key, Class<T> type) 메서드는 단일 Class 기반 역직렬화만 지원하므로 제네릭 복합 타입을 안전하게 처리하려면
TypeReference<T> 오버로드를 추가하세요: RedisCacheManager에 public <T> Optional<T>
get(String key, com.fasterxml.jackson.core.type.TypeReference<T> typeRef) 메서드를
추가하고 내부에서 readTemplate.opsForValue().get(key)로 JSON을 읽은 뒤
objectMapper.readValue(json, typeRef)로 역직렬화하며 기존 get(Class<T>)와 동일한 null 처리 및 예외
로깅(log.warn("Redis GET 실패 - key: {}", key, e)) 동작을 재사용하도록 구현하세요; 기존
get(Class<T>)는 그대로 유지해서 하위 호환성을 보장하세요.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/product/ProductQueryPerformanceTest.java`:
- Around line 124-126: Replace the System.out.println calls in
ProductQueryPerformanceTest with an SLF4J Logger: add a private static final
Logger (LoggerFactory.getLogger(ProductQueryPerformanceTest.class)) to the class
and change each println (the blocks around the "=== 방식 A (비정규화) ===" output and
the other occurrences at the mentioned spots) to logger.info(...) so test output
goes through the logging framework and can be filtered by CI; ensure the
formatted messages remain the same and adjust imports to include
org.slf4j.Logger and org.slf4j.LoggerFactory.
- Around line 23-94: The test data created in setUp() (method setUp annotated
with `@BeforeAll`) is never cleaned and commits unconditionally, so add a
complementary `@AfterAll` method (e.g., tearDown) that opens an EntityManager,
begins a transaction, deletes rows from favorite, product_like_stats, product,
member, and brand (in that or safe FK order), commits and closes the EM in a
finally block; also make setUp() robust by wrapping each transactional block in
try/catch and calling em.getTransaction().rollback() on exceptions (and closing
the EntityManager in finally) so partial failures don’t leave data behind.
- Around line 66-72: The insert uses RAND() causing non-deterministic favorites;
change the WHERE clause in the em.createNativeQuery(...) favorite insert to a
deterministic predicate (e.g., replace "WHERE RAND() < 0.05" with a
modulus-based condition such as "WHERE MOD(m.id + p.id, 20) = 0" or another
fixed hash/row-number expression) so the favorite generation is reproducible
across runs; update the INSERT statement inside the createNativeQuery call that
builds favorites to use this deterministic filter.